Telephony users today can modify some of their communication service settings using their user device via a user interface, for example a telephony user interface. For example, a user can switch on unconditional call forwarding by dialing an access code (say, *72), and then dialing the telephone number they want calls to be forwarded to. There are different specifications for communication services, for example as specified by Telcordia™ and the European Telecommunications Standards Institute (ETSI), each providing a different user experience. With ETSI-style services, the telephone switch or feature server providing the communication service plays announcements to the user to explain the status of the communication service, for example to prompt them to enter a forwarding number. With Telcordia-style services, the user hears tones instead; in the unconditional call forwarding example above, the user would hear a stutter dial tone after dialing *72, a confirmation tone after dialing a valid forwarding number, or a reorder tone if there was a problem.
With ETSI-style services, the telephone switch or feature server sets up a media stream between the user's telephone and a media resource server in order to play announcements for communication services. Once the media stream is set up, the telephone switch or feature server instructs the media resource server to listen for digit tones in the media stream in order to collect digits from the user device for implementing the settings modification desired by the user. This introduces a window after the user has dialed their initial set of digits but before digit detection has been set up on the media resource server, during which no digit detection is taking place; any digits the user dials during this window will be lost. ETSI users therefore need to wait until the announcement starts before dialing any further digits.
ETSI supports a mechanism for the setting up of telephone calls which involves a telephone switch or feature server transmitting a SIP 484 Address Incomplete message with a Min-Digits: X function, where X is the number of digits transmitted so far plus one. This process is repeated to collect a single additional digit at a time until a full telephone number is collected.
With Telcordia-style services, there are typically no announcements to play, and most access gateways which provide communication services are capable of playing the relevant tones themselves. The telephone switch providing telephony services to the user will therefore usually ask the access gateway to play the tones and collect further digits directly, without a media resource server being involved. This means that there is no window during which digits can be lost, and consequently, many Telcordia subscribers are used to being able to dial an access code plus additional digits very quickly, for example activating call forwarding using speed dial functionality.
Problems arise where the Session Initiation Protocol (SIP) is used between the user and the telephone switch or feature server providing communication services, for example because the user has a SIP telephony device, their telephone is connected to a SIP Broadband Loop Carrier, or because the feature server has a SIP interface to a telephone switch or call control function. Unlike gateway control protocols such as Media Gateway Control Protocol (MGCP) or H.248 (‘Megaco’), SIP is peer-to-peer and has no mechanism by which a telephone switch or feature server can instruct a user device to play a tone or collect digits. Existing implementations overcome this problem in one of three ways, but all of them are flawed.
A flow diagram for a first flawed prior art attempt is shown in FIG. 1 where a user with a SIP device picks up the handset of their SIP device in step 1a and is required to dial the complete set of digits including an access code (step 1b) for the communication service they require, in this case access code *72 for an unconditional call forwarding service, and telephone number digits 15552001234 (step 1c) all at once. The user does not hear any tones between digit sequences to reassure them that all is OK, and either has to wait for a timeout (for example 4 seconds or so) or press # or “Dial” on their SIP device when finished before the feature server is finally contacted with a SIP INVITE message in step 1d. This is a clearly unsatisfactory user experience.
A flow diagram for a second flawed prior art attempt is shown in FIG. 2 where a telephone switch or feature server uses a media resource server to play tones and collect digits from the SIP device of the user. The user picks up the handset of their SIP device in step 2a and dials the access code *72 for the communication service they require in step 2b. The SIP device sends a SIP INVITE message containing the access code to the feature server in step 2c. The feature server sets up a session between the SIP device and a media resource server in step 2d, including instructing the media resource server to play a stutter tone to the user's SIP device and collect digits entered by the user on their SIP device. The media resource server sends Session Description Protocol (SDP) data for a Real-time Transport Protocol (RTP) stream to/from the feature server in step 2e. The feature server forwards the SDP data on to the SIP device in a SIP 200 OK message in step 2f. The media server then plays a stutter tone to the user's SIP device in step 2g to inform the user that he may begin to enter digits. The digits from the user's SIP device are transmitted into the media stream to the media resource server in step 2h and then on to the feature server in step 2i. This approach suffers from the same restriction as with ETSI-style services in that the user must wait until the media stream has been set up before they dial additional digits. If additional digits are dialed too early, they may be lost.
A flow diagram for a third flawed prior art attempt is shown in FIG. 3 where a user's SIP device has enough intelligence to understand each of the access codes and their user experience and so plays the correct tone(s) and collects any required additional digit(s) itself before sending the complete set of digits to the telephone switch or feature server. The user picks up the handset of their SIP device in step 3a and dials the access code *72 (step 3b) for the communication service they require. The user's SIP device recognises the access code as being for an unconditional call forwarding communication service and determines (or assumes) that the user has a variable variant of unconditional call forwarding which requires entry of additional digits in the form of a telephone number to which calls should be forwarded to. The user's SIP device then plays a stutter dial tone to inform the user that they may start entering a telephone number in step 3d which the user enters in step 3e. The SIP device then sends the access code and entered telephone number digits to the feature server in step 3f. The above operation by the SIP device can be difficult to achieve, even with a SIP device with upgraded capabilities because there are a number of communication services with different sequences of tones and digits, and different users may have different combinations of these services. Further, the same access code may require different behaviour depending on the variant of communication service the subscriber has; for example, a subscriber with a fixed variant of call forwarding just dials *72 and should not be played a stutter dial tone or be prompted to enter additional digits.
There is therefore a need to provide improved ways of interfacing with communication services in a SIP environment.